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REMARKS 



STATUS OF CLAIMS 



AU of original claims 15-18 and claims 19-33, added by amendment, are pending in the 
application. All claims were rejected under several arguments in a non-final office action of 
3/22/2002 and a final office action of 1/5/2004. Applicant responded to those arguments of 
rejection in responses filed 6/20/2003, 10/24/2003 and 4/20/2004. After filing a Request for 
Continued Examination, the Office withdrew its previous rejections in an office action dated Jan. 
3, 2005, and rejected all of claims 15-18 and 19-33 under 35 U.S.C. §§ 102(e) and 103 relying on 
U.S. Pat. Publ. 2001/001 1250 ("Paltenghe") and official notice. 

ARGUMENTS IN GENERAL 

For the sake of efficiency, applicant will first discuss the Paltenghe reference (U.S. Pat. Publ. No. 
2001/0011250 Al) against the pending claims generally, pointing out general differences from 
what is claimed or what is described in the present patent specification. In that discussion, that 
reference will be referred to as if Paltenghe was the sole inventor, for the sake of simplifying the 
discussion. Applicant will afterward address the specific points of argument in the office action 
of 1/3/2005 in detail. 

THE PALTENGHE REFERENCE 

The Paltenghe reference is directed to generally to a system that includes an "Information Bank" 
for information storage containing personal data of "consumers " which appear to be individuals 
that subscribe to the service of the system, flffl 10-13, 15-21 and 46-48.) In connection with that 
system, several subsystems are disclosed providing consumer services including data backup fl[ 
22), cryptographic key /data escrow 23, 25 and 60), loyalty awards flHf 27, 61 and 64-66), 
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form filling 49-50), digital signing flffl 51-56) and event notification 28 and 67), which 
clearly appear to be too unrelated to the claims to be usefully used in arguments of rejection. Of 
Paltenghe's subsystems, only three appear can possibly bear any relation to product purchasing 
activity with merchants. The first is a "search and offer" subsystem disclosed in paragraphs 61 to 
63 and figure 8 and summarized in paragraphs 17, 18 and 26. The second is the "coupon and 
loyalty management program" disclosed in paragraphs 64 to 66 and figure 9 and summarized in 
paragraph 27. The third and last is the "anonymous shopping service" described in paragraphs 68 
to 72 and figure 1 1 and summarized in paragraphs 29 and 30. The arguments of rejection point 
loosely to either the search and offer subsystem, the anonymous shopping service or a 
combination of the two. 

POINT-SPECIFIC ARGUMENT 

The Paltenghe disclosure is primarily concerned with describing a system for storing, managing, 
transferring and protecting consumer data in an "information bank." fl[ 1 1 .) These arguments will 
focus on the three sub-systems mentioned above, as the remaining disclosure of Paltenghe 
appears clearly to have no significance to patentability of the present claims. 

Applicant reminds that the meaning of claims may not be construed arbitrarily, but the claims 
must be considered using the broadest reasonable interpretation consistent with the specification . 
MPEP § 21 1 1. Applicant will refer to the present specification in these arguments as a guide to 
what a reasonable interpretation might be. 



A. Paltenghe does not disclose a system that provides transaction processing for order items from 
vendors, or more specifically processing of order items by use of a transaction processing system 
and back-end recessing systems. 



First considering the search and offer subsystem, that does not provide direct interaction of any 
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kind between consumers and merchants. Rather, Paltenghe's "Information Bank" provides a 
"brokering* 1 function fl| 62, line 11) between consumers and merchants of offers. One of the 
purposes of Paltenghe's system is to avoid providing the identification of the consumer the 
merchant, protecting his privacy: "Fuzzy logic matching is used to match merchant and 
consumer, on an anonymous basis so that neither knows the identity of the other, and allow 
consumers to search, shop and negotiate anonymously ..," flf 26.) To this purpose the information 
bank receives offers from merchants through a "merchant gateway module 131", which offers are 
forwarded by the information bank to consumers whose profiles match an offer. fl[ 62) 
Consumers interested in inquiring further "issue a request or buy request" to the information 
bank consolidatOT. flf 62) The information bank consolidator then forwards these consumer 
inquiries to the merchant, which may occur "in bulk" with other offers to the merchant. (fl 62.) 
The transmission of inquiries may occur in bulk because no consumer is identified for any order, 
and because orders need not be immediately placed with a merchant or immediately filled. 



Of note, discussion of shopping, product ordering, and transaction and payment activity between 
a consumer and a merchant is absent from the disclosure of the search and offer subsystem. With 
this system, the disclosure of Paltenghe takes us up to the point of potential first contact between 
a consumer and a merchant, but no further, and does not disclose selection, purchasing, payment 
or order fulfillment activity between those parties. 

The arguments of rejection briefly point to the "offers" and "$ for brokerage" in figure 8 to 
provide support for "vendor-specific processing rules [in a database] ... to process ... order items 
for a particular vendor." That argument is clearly erroneous for two reasons. First, the "offers" 
made are not sufficient to form an object in which a transaction may occur with a vendor or 
merchant; Paltenghe's offers are merely submissions to the information bank to perform a 
consumer profile search and forward operation. Second, the "$ for brokerage" is exactly that - it 
is money paid by the merchant to the information bank for the service of operating the search and 
offer system rather than money paid in the course of processing "order items for a particular 
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vendor" as in claim 16, for example. Paltenghe clarifies this in paragraph. 62: "The merchant 133 
will then pay a fee for the brokerage service ..." Additionally, Paltenghe discloses variations on 
this fee in paragraph 63, however he does not there describe how consumers would select, 
purchase or pay for their orders from the merchants nor provide for processing of transactions of 
consumer orders. 

Next considering the coupon and loyalty management program, we see that the various 
incentives (coupons, tokens, tickets, etc.) are tracked in an "electronic wallet" that is a "mobile 
container." flffl 27 and 64) The redemption of coupons is described in paragraph 66 as follows: 
"When the consumer wished to redeem these coupons, they would forward them to the 
information hank retailer gateway module 137 which presents the coupons to the information 
bank clearinghouse module 139 for settlement. The information bank manufacturer gateway 
module 141 then would issue an appropriate credit back through the information bank 
clearinghouse module 139 to the appropriate retailer 147 in exchange for the redeemed coupon." 
The interaction with the consumer 25 in figure 9 is shown to be between the manufacturer 145 
(who supplies the coupon to the consumer) and with the information bank 137 (who receives the 
coupon for redemption). But at most that discloses the redemption of coupons, and not 
transactions for order items as claimed, for example, in claim 15. 

Finally considering the anonymous shopping service, Paltenghe describes that "consumers are 
billed internally by the information bank, so no consumer payment information crosses the 
Internet or is made available to merchants" in it's "anonymous shopping service." flffl 29 and 71 .) 
Furthermore, "orders to popular merchants are consolidated and paid in lump sum." flffl 29 and 
71.) Because Paltenghe's billing transaction with merchants occurs apart from a customer's order 
(in lump sum with the payment of other consumer orders,) there is no need for a transactional 
processing system. Indeed, in the system of Paltenghe it would be advantageous to perform 
merchant payment manually, as each merchant would have its own billing procedure, and as that 
was what was conventionally known at the time Paltenghe filed his application. Indeed, in 
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Paltenghe's system there appears to be no justification or motivation for fashioning a 
transactional processor that communicates with a back-end system or payment verification 
system, as the cost of hiring a person to provide the transfer manually would be far less than the 
development and maintenance costs of a transactional system as claimed, particularly because in 
Paltenghe's system payments to merchants are made "in bulk. " 

B. Paltenghe does not di sclose rules or logic for processing orders 

As discussed above, Paltenghe does not disclose direct interaction between consumers and 
merchants, but rather that system acts as a broker between the two to maintain anonymity. The 
meaning of processing rules and runtime payment logic are given in the specification: 

The local workflow and pu rchasing rules 50, 54 are generally specific to each vendor, 
and set forth particular rules that may affect how the specific commerce system deals 
with certain transactions. For example, a particular customer 42 may only be authorized 
to make a purchase of less than $5,000, and if the items stored in the local basket 52 
exceed this amount, then authorization from another individual is required. In this 
situation, the system can be programmed to send an email or other notification to the 
other individual to obtain authorization. Other, more complicated workflow and. 
purchasing rules may be implemented within each vendor system. (Page 10, lines 10-17 
of specification.) 

Turning now to the specific transaction processing steps, at step 96, the ICC transaction 
processor 12 queries the merchant database 18 in order to obtain the merchant-specific 
transaction processing rules. Each merchant for vendor 1 ! can hav e their own specific rules 
setup for determining how their transactions are processed by the common back-end 
system 12. In this manner, although the ICC transaction processor 12 is common to all of 
the participating vendor commerce systems 34, 36, 38, each vendor commerce system 
can have a customized back-end processing scheme . Merchant-specific data processing 
rules stored in the merchant database 18 may include (1) merchant authentication 
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information or a merchant account number; (2) preferred payment processor information, 
such as what payment verification ion system to use for transactions; (3) order 
fulfillment instructions; (4) accounting/billing instructions, and (5) other merchant- 
specific rules, including, optionally, certain merchant-specific runtime scripting 
algorithms. (Page 21, lines 3-13) 

After the ICC transaction processor 12 has obtained the merchant-specific rules, at step 
98 it queries the customer database 58 in order to obtain any customer-specific 
transaction processing rules . Although these customer-specific rules may take a variety 
of forms, in the preferred embodiment of the invention, these rules will generally include 
a customer account number (for verification purposes) and one or more runtime scripts 
for providing interactive feedback about the processed transactions to the customer's 
system 42. For example, the customer system 42 may be operating some type of 
enterprise system software coupled to a purchasing system for tracking purchased items. 
In this situation, a runtime script can be stored at the customer database 58 and processed 
by the ICC transaction processor 12 at the time that relevant transaction items are 
processed- In this manner, information regarding actual purchases that are committed by 
the system 1 6 can be transmitted back to the customer's system 42 in a format that is 
compatible with the customer's purchasing software system. Other types of runtime 
scripting algorithms could certainly be implemented between the ICC transaction 
processor 12 and the customer's system 42. (Page 22 line 9 to page 23 line 3.) 

At step 2, the payment proxy 16 executes the runtime payment logic 62 in order to 
determine how to process the particular trans action authorization request The runtime 
payment logic 62 can take many forms and can operate many functions, in addition to 
simply determining where to route the particular transaction request. For -example, 
various business rules particular to a certain merchant cou ld be executed by the runtime 
payment logic. These business rules may take the form of scripting information that is 
stored in the associated merchant database 1 8. As described above, the merchant 
database 18 may include a variety of runtime scripts for instructing the E-Commerce 
system how to process the transactions for a particular merchant It is the payment 
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proxy's runtime payment logic 62 that executes these stored scripting commands to, for 
example, determine which payment verification system 22, 24 is operating most 
efficiently, or most inexpensively, etc., and then to route the transaction authorization 
based on the results of this determination. Many other real-time processing functions 
could also be implemented by the runtime payment logic 62, such as, for example, 
applying additional calculations to a particular order; interfacing information with an 
associated order fulfillment system; sending transaction alerts or other messages to an e- 
mail or pager system when certain products are purchased, certain price thresholds are 
exceeded, etc.; or to interface with other databases to either receive or update legacy 
data. (Page 25 line 15 to page 26 line 10.) 

From the above, it is clear that processing rules are instructions that permit custom treatment of 
merchants/vendors or customers, and provide for behavior in the transaction prescribed for or by 
particular merchants or customers. Rules are not mere information, such as account numbers and 
billing addresses, because rules define the functionality of the system with respect to the 
particular merchant or customer. Likewise runtime payment logic provides processing that 
determines how to process transaction requests for particular merchants and/or customers. 
Paltenghe does not include processing rules specific to a merchant or customer, because in that 
system all are provided the same treatment, as will now be shown. 

First considering the "search and offer" subsystem, there is not disclosed to be processing of 
orders by any method. Paltenghe only says for this subsystem is that "when a consumer 25 
indicates interest in a particular offer, they will issue a request or a buy request back to an 
information bank consolidator function in module 129, which will then forward this to the 
merchant 133, either individually or in bulk with other consumer offers." (fl 62) That does not 
disclose custom processing for a particular merchant/vendor or customer, nor rules of any kind. 

As to the "coupon and loyalty management program," Paltenghe discloses "When the consumer 
wished to redeem these coupons, they would forward them to the information bank retailer 
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gateway module 137 which presents the coupons to the information bank clearinghouse module 
139 for settlement. The information bank manufacturer gateway module 141 then would issue an 
appropriate credit back through the information bank clearinghouse module 139 to the 
appropriate retailer 147 in exchange for the redeemed coupon. All of these functions can be 
implemented routinely by those of ordinary skill in the art using existing hardware and software 
tools and devices once the broad functionality described in detail herein is known." fl[ 66) Issuing 
credit to a merchant has no quality of processing dependent on an individual merchant, nor does 
redeeming a coupon suggest the processing of consumer-specific rules. 

As to the "anonymous shopping service," Paltenghe discloses 'This function consolidates orders 
to popular merchants and pays these merchants directly in a lump sum, together with a summary 
of orders and corresponding ship- to addresses. The consumer 25 is billed internally so that their 
credit card and other identification information is never exchanged over the Internet" Paltenghe 
does not disclose that the procedure for fulfilling orders, paying merchants for orders, or 
receiving payment from customers may be customized for any party in that subsystem. 

The arguments of rejection point to "FIG 8, Offers, $ for brokerage" and "items 123 and 125" in 
Paltenghe to show a merchant or a customer database containing processing rules. Item 123 is the 
portion of the Information Bank containing a Courtesy Account and a Service Account, and item 
125 contains a Value Generation Account. Accounts might be referenced or identified by rules, 
but accounts and account information are not rules, because they do not determine how 
transactions are processed As was said above, Paltenghe's offers are merely submissions to the 
information bank to perform a consumer profile search and forward operation, and have nothing 
to do with processing transaction order items. Again, "$ for brokerage" is money paid by the 
merchant to the information bank for the service of operating the search and offer system, and 
not money paid in the course of processing "order items for a particular vendor." 

Paltenghe does not disclose processing rules or logic as recited in claims 16, 17 and 19-33, which 
are allowable over that reference. 
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C. Paltenghe does not disclose a global shopping basket (storing order items for a cu stomer! 

Applicant would first like to point to the following statements in the specification that define the 
term "global shopping basket": 

The global shopping bas ket 14 aggreg ates transaction information from numerous vendor 
commerce systems during a customer's shopping session. By providing this "global" 
shopping basket 14 at the ICC transaction processor 12, a customer 42 can browse, 
search, and purchase multiple products from multiple vendor commerce systems 34, 36, 

38, and yet when the customer 42 is ready to leave the system, only a single, unified 

checkout is required. (Page 13 lines 6-11.) 

FIG. 3 is a flowchart detailing the preferred method steps carried out by the ICC 
transaction processor during a global checkout procedure. At step 90, the ICC transaction 
processor 12 queries the global basket 14 and segments the transaction packet 
information stored there for the particular customer session into a plurality of individual 
transaction order items 44E, and then aggregates all of the transaction order items 44R by 
merchant . This step results in a plurality of transaction order items that are grouped by 
merchant for processing according to the specific transaction processing rules of the 
particular merchant. (Page 20 lines 12-18.) 

From the specification, a global shopping basket stores product selections by vendor, whereby in 
a unified checkout a vendor can be appropriately identified at the time transactions are to be 
processed. In other words, a global shopping basket permits a consumer to visit multiple 
merchants without checking out at the end of a customer's visit to each merchant/vendor system, 
but rather checking out at the end of the visit to the "electronic mall." 

First considering the "search and offer" subsystem, Paltenghe discloses that "when a consumer 
25 indicates interest in a particular offer, they will issue a request or a buy request back to an 
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information bank consolidator function in module 129, which will then forward this to the 
merchant 133, either individually or in bulk with other consumer offers." (J 62) At most, 
Paltenghe suggests that several consumer inquiries (not purchase orders) be submitted to a 
merchant together. But even if a container of inquiries was a "basket", it does not store "product 
order items" as in claim 15. It does not contain "selections in combination with information 
whereby a vendor may be identified for each selection" as in claim 19 because Paltenghe's 
container does not store selections, but rather consumer inquiries, and would not need to contain 
vendor identification information, because each inquiry in Paltenghe's container would be 
destined for the same vendor. 

As to the "coupon arid loyalty management program," that has nothing to do with product 
selection items but rather coupons or other tokens. 

As to the "anonymous shopping service," Paltenghe states in paragraph 70 that "This feature is 
more like a "shopping cart" on a website or service provider site on the Internet, where the 
shopper can span multiple merchant sites and Shopping sessions and create a consolidated order." 
What is a "consolidated order" in this subsystem? Paltenghe tells us in paragraph 71: "This 
function consolidates orders to popular merchants and pavs these merchants directly in a lump 
sum, together with a summary of orders and corresponding ship-to addresses. The consumer 25 
is billed internally so that their credit card and other identification information is never 
exchanged over the Internet." Therefore each consolidated order is to a single merchant , 
consolidating the orders of several consumer s. That is not a global shopping basket, because 
aggregation according to merchant is not possible, given that only orders to a single merchant are 
included in Paltenghe's consolidated, order. What does it mean that the "shopper can span 
multiple merchant sites?" This merely means that the anonymous shopping service may operate 
with several merchant sites, permitting a shopper to visit successive merchant sites 
(anonymously) with a confirmation procedure following each visit. A confirmation procedure 
(i.e. asking the consumer to confirm that he intends to order the selected merchant items) rather 
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than a checkout procedure would be used, because Paltenghe's payment occurs afterward or apart 
by internal customer billing and payment in lump sum to the merchant fl[ 71). A global shopping 
basket, storing items from several merchants, is not needed nor inherent in the anonymous 
shopping service, because a consumer's order items (selected from single vendors only) can be 
consolidated with other consumer orders for the participating merchants at the time they are 
made. 

D. Palteng he does not disclose a payment pro xy or a payment proxy interface. 

The description of a payment proxy interface may be found generally between page 23 line 1 9 
and page 27 line 8 of the specification, a portion of which is reproduced here: 



FIG. 4 is a logical block diagram showing the preferred interaction between the ICC 
transaction processor 12 and the payment proxy system 16 shown in FIG. l. The 
payment proxy system 16 provides a universal payment verification interface between 
the ICC transaction processor 12 and a plurality of payment verification systems 22, 24. 
Although described in the context of FIG. 1, the payment proxy system 16 can be used 
with a variety of different frameworks and different E-Commerce systems, and is not 
limited to the system shown in FIG. 1 . 



Preferably, the payment proxy system 16 includes a front-end payment proxy interface 
module 60, runtime payment logic 16, and a plurality of payment connection modules 64. 
As shown in FIG, 1, in the preferred framework, the payment proxy system 16 is also 
coupled to a merchant database 18 and a transaction capture database 20. The elements 
of the payment proxy system 16 are preferably implemented via software instructions 
stored within the payment proxy system 16, but could, alternatively be implemented in 
hardware or a mix of hardware and . software instructions. The software instructions for 
carrying out the functionality of the payment proxy could be programmed using a variety 
of different programming techniques and using a variety of different programming 
languages as those of skill in this art will appreciate. 
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The basic purpose of th e payment proxy system 16 is to provide a universal payment 
verification interface between one or more transaction processing systems far other E- 
Commerce systems) and a plurality of payment verification hosts. In this manner, 
flexible and efficient payment verification services can be provided to a plurality of E- 
Commerce systems, without any need for the E-Commerce systems to k now the details 

of comnmni^tiAg with gnd effecting transactions with the payment verification system^ 
Such a universal E-Commerce payment verification interface is unknown in the prior art. 



Having determined how to process the particular transaction authorization request ,, thfi 
payment proxy 16, at step 3, then sends the transaction to the proper payment connection 
module 64. The payment connection modules 64 each provide interface programming for 
instructing the payment proxy 16 how to communicate with the plurality of payment 
verification systems 22, 24. At step 4, the transaction authorization is routed to the 
proper payment verification system. The payment processor then authenticates the 
transaction request at step 5 and transmits back to the payment proxy system 16 a failure 
code (indicating that the transaction was not authorized), or an "auth-code" (indicating 
that the transaction was authorized.) The payment proxy 16 then routes the code back to 
the ICC transaction processor 12 (or other E-Commerce system) at step 6, which, at step 
7, then reacts to the code by, for example, sending a message to the customer indicating 
whether the transaction has failed or has been autiiorized. 

Using the specification as a guide, a payment proxy includes a universal payment verification 
interface between one or more transaction processing systems (or other E-Commerce systems) 
and a plurality of payment verification hosts, thereby presenting a universal transactional 
interface to E-Commerce systems. A payment proxy provides at least three functions: 1- 
receiving transaction authorization requests through a common interface, 2- routing transaction 
authorizations to the proper payment verification system, and 3- receiving and returning a failure 
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code or an authorization code indicating failure or success. 

The "search and offer" subsystem cannot include a payment proxy system, because that 
subsystem does not provide handling for payments. The same holds for the "coupon and loyalty 
management program," because payments are not handled. 

In the "anonymous shopping service," "The consumer 25 is billed internally so that their credit 
card and other identification is never exchanged over the Internet." Paltenghe provides no further 
detail. The internal billing might be a manual operation, or it might be facilitated by automation. 
In any event, the merchants are paid in a "lump sum", and thus as merchants are paid from the 
Information Bank and not through a payment verification system, there is only one way for the 
merchants to receive payment in Paltenghe's system and no payment proxy is needed. 

E. Paltenghe does not disclose the use of both a local shopping basket and a global shopping 
basket to fil l customer order items, nor the transference of data in-between. 

First considering the "search and offer" subsystem, no shopping baskets are used, because only 
offers and inquiries are transferred. As to the "coupon and loyalty management program," that 
system does not include a shopping basket. 

As to the "anonymous shopping service," it is argued above that a global shopping basket is not 
disclosed in this sub-system. However, even if it was, there is no disclosure of a local shopping 
basket storing consumer selections, the contents of which are transferred to a global shopping 
basket as in claim 18. 

Applicant now addresses each item of the latest office action, and has enumerated the arguments 
for convenient reference. 
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1. The Office responded to applicant's request for continued examination by considering 
applicant's prior remarks, and further conducted a search and cited new grounds of rejection as 
addressed below. 

2. 35 U.S.C. § 102 is cited in support of arguments of rejection made below. 

3. Claim 15 is rejected under 35 U.S.C. § 102(e) as being anticipated by U.S. Pat. Publ. 
2001/001 1250 ("Paltenghe"). It is alleged that Paltenghe discloses all the steps of (A) connecting 
to an E-Commerce portal, (B) linking from the E-Commerce portal to a vendor commerce system 
associated with the E-Commerce portal, (C) browsing a local catalog of products stored at the 
vendor commerce system and selecting a particular product for purchase, (D) transmitting a 
transaction packet from the vendor commerce system to a common transaction processing system 
via the Internet, and storing the transaction packet in a global shopping basket, (E) returning to 
step (A) and repeating steps (B), (C) and (D) until no additional products are to be purchased, (F) 
segmenting the transaction packet information stored in the global shopping basket and 
aggregating individual product order items by vendor, and (G) processing the individual product 
order items for each vendor at the transaction processing system by communicating transaction 
information between the transaction processing system and a plurality of back-end processing 
systems. 

Applicant traverses this rejection on grounds that at least steps D, E, F and G are not disclosed by 
Paltenghe. 

As for step F, segmenting the transaction packet information stored in the global shopping basket 
and aggregating individual product order items by vendor, Paltenghe does not disclose a global 
shopping basket, as argued above. As to paragraph 71 cited in (he arguments of rejection, the 
consolidation function does not store product selections by vendor, but rather consolidates the 
orders of several customers to one merchant as argued above. Furthermore, Paltenghe's 
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consolidation does not facilitate a unified checkout procedure where a customer can shop at 
several E-Commerce sites without performing a checkout procedure at each site. Nowhere in 
Paltenghe is disclosed a global shopping basket or a global or unified checkout procedure. 

As for step D, because Paltenghe does not disclose a global shopping basket, Paltenghe cannot 
disclose storing transaction packets or product selections in a global shopping basket. Step E 
cannot be disclosed by Paltenghe, because that step requires repetition of step D. Additionally, 
Paltenghe offers no disclosure or suggestion of processing product items that are selected from a 
plurality of vendor commerce systems and stored in a common shopping basket. As argued 
above, the subsystem described in paragraph 70 of Paltenghe is not a global shopping basket, and 
likewise successive operations of the procedure described in paragraphs 69-72 of Paltenghe falls 
outside the scope of the claims with respect to step E. 

As for step G, Paltenghe does not disclose the "processing of individual product order items'', as 
argued in argument "A" above. Figure 8 does not disclose a transactional processing system, but 
rather a search and offer system as argued above. 

4. Claim 16 is rejected under 35 U.S.C. § 102(e), with allegations that Paltenghe discloses the 
steps of (G)(1) querying a vendor database to obtain vendor-specific processing rules used by the 
transaction processing system to process the transaction order items for a particular vendor; and 
(G)(2) querying a customer database to obtain customer-specific processing rules used by the 
transaction processing system to process the transaction order items for a particular customer. 
(The arguments of rejection, although referring to claim 15, will be presumed to refer to claim 16 
as only in 16 are these steps recited.) 

Applicant traverses this rejection on grounds as recited for claim 15 and further that Paltenghe 
does not disclose processing rules for either processing order items for a particular vendor or for 
a particular customer, as argued above. The system described in connection with figure 8 
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concerns offers and not order items or transactions, and the brokering service is provided 
between the Information Bank and merchants, as argued above. The items numbered 123 and 
125 are accounts, which are not databases, rules or transaction order items, and do not bear upon 
the patentability of this claim, as argued above. 

5. Claim 17 is rejected under 35 U.S.C. § 102(e), with allegations that Paltenghe discloses a 
system including (1) a payment proxy interface for communicating information to and from the 
transaction processor, (2) runtime payment logic for determining, in real-time, how to process a 
particular transaction request transmitted to the payment proxy from the transaction processor; 
and (3) a plurality of payment connection modules coupled to the runtime payment logic for 
interfacing the transaction request to one of a plurality of payment verification systems. (Again, 
the arguments of rejection refer to claim 16, but applicant will presume a reference to claim 17 
was intended as claim 16 does not recite these elements.) 

Applicant traverses this rejection on grounds that Paltenghe does not disclose a payment proxy 
interface nor runtime payment logic, as argued above. Figure 1 does not disclose a payment 
proxy interface nor a plurality of payment connection modules. The system described in 
connection with figure 8 does not concern transactions, but rather offers, as argued above. 

6. Claims 18-23 are rejected under 35 U.S.C. § 102(e) with allegations that Paltenghe discloses 
all the elements of those claim, referring only to arguments made for claims 15-17. Those 
arguments attempt no specific reference in Paltenghe in which the claim elements are alleged to 
be disclosed, and amount to an imprecise and insufficient general allegation that the claim 
elements are disclosed by the reference. 

For claim 18, applicant traverses this rejection on grounds that Paltenghe does not disclose a 
global shopping basket, the use of a global shopping basket in combination with a local shopping 
basket, nor a payment proxy system, as argued above. 
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For claim 19 and for dependent claims 20-23, applicant traverses this rejection on grounds that 
Paltenghe does not disclose a transaction processor that includes a global shopping basket, 
merchant-specific transaction processing rules or a database containing the same. 

Further for claim 21, Paltenghe does not disclose a local catalog of products or a local shopping 
basket in a vendor commerce system. 

Further for claim 22, Paltenghe does not disclose a local customer directory or local workflow 
rules. 

Further for claim 23, Paltenghe does not disclose the use of a predefined format that is used each 
time a customer purchases a product from a vendor commerce system, nor does it disclose the 
storing of purchase information to a global shopping basket. 

7. Claim 25 is rejected under 35 U.S.C. § 102(e) with allegations that Paltenghe discloses vendor 
commerce systems coupled to a transaction processor via the Internet. 

Applicant traverses this rejection on grounds recited for claim 19, and further that a coupling 
from a transaction processor to a vendor commerce system, by the Internet or any other means, is 
not disclosed by Paltenghe. Paragraph 10 of Paltenghe discloses that consumers have access to 
the Information Bank through the Internet. There is nothing there disclosed of transaction 
processing or vendor commerce systems. 

8. 35 U.S.C. § 103 is recited for the rejections that follow. 

9. Claim 24 is rejected under 35 U.S.C. § 103 with allegations that Paltenghe teaches 
authenticating parties using encryption methods, and further that it was old and well known in 
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the art at the time of the invention to include in transmission packets a header including 
information as included in claim 24. The arguments of rejection do not point to a reference for 
asserting the obviousness of including (1) and order heading including customer authentication 
information and merchant authentication information, (2) a time stamp and (3) one or more order 
entry items, which are therefore cited by official notice. The arguments of rejection allege only 
"that it was old and well known in the art at the time of the invention to include in transmission 
packets a header including information as taught by the instant claims." No evidence is cited in 
the record for that allegation, and Applicant asserts that that is an incorrect statement, and 
challenges the Office under MPEP § 2143.04 "C" to provide documentary support. 

Furthermore, the Office has violated its policy with regard to Official Notice, which policy is that 
"Official notice should only be taken by the examiner where the facts asserted to be well-known, 
or to be common knowledge in the art are capable of instant and unquestionable demonstration 
as being well-known" and "capable of such instant and unquestionable demonstration as to defy 
dispute." MPEP § 2143.04 "A." 

Applicant points to the following instructions in the Manual of Patent Examining Procedure: 

"To establish a prima facie case of obviousness, three basic criteria must be met. First, there must 
be some suggestion or motivation, either in the references themselves or in the knowledge 
generally available to one of ordinary skill in the art, to modify the reference or to combine 
reference teachings . Second, there must be a reasonable expectation of success . Finally, the prior 
art reference (or references when combined) must teach or suggest all the claim limitations ." 
MPEP § 2142, page 2100-124 

"The mere fact that references can be combined or modified does not render the resultant 
combination obvious unless the prior art also suggests the desirability of the combination." 
MPEP § 2143.01, page 2100-131 
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"A statement that modifications of the prior art to meet the claimed invention would have been " 
'well within the ordinary skill of the art at the time the claimed invention was made' " because the 
references relied upon teach all the aspects of the claimed invention were individually known in 
the art is not sufficient to establish a prima facie case of obviousness without sopiq objective 
reason to combine the teachings of the references." MPEP § 2143.01, page 2100-131 

Applicant traverses this rejection on grounds as recited for claims 19 and 23 , and further that 
neither Paltenghe nor the arguments of Official Notice sufficiently teach or suggest (1) and order 
heading including customer authentication information and merchant authentication information, 
(2) a time stamp and (3) one or more order entry items, and even if those were taught there is no 
sufficient motivation to combine the references. 

Additionally, the alleged motivation to combine "because this was a notoriously well known 
means for sending identifying information of a transaction and would have benefited Paltenghe 
by providing an efficient means for providing rudimentary transaction information between the 
parties" is an insufficient motivation. That alleged motivation is nothing more than an offhand 
statement that the elements of the claim could have been advantageously combined. Additionally 
the arguments of rejection fail to consider that an essential asserted advantage of the Paltenghe 
system with respect to interactions with merchants is to maintain consumer privacy and 
anonymity. The subject matter of claim 24 requires that transaction packets include customer 
authentication informatioq and be sent from a vendor commerce system . As providing customer 
authentication information to vendor commerce systems, by which a vendor could track and 
identify individual customers, would destroy anonymity, combining Paltenghe with the elements 
of official notice would render Paltenghe unfit for its intended purpose, (see MPEP § 2143.01 pg. 
2100-131 and Paltenghe ffl 6, 17, 26, 29, 61, 68-72 and the abstract) 

10. Claims 26-33 are rejected under 35 U.S.C. § 103 with allegations that Paltenghe teaches 
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payment (conducted through) an intermediary between a merchant and a customer through a 
proxy wallet server that authenticates. The arguments of rejection then casually state that all the 
remaining claim elements were old and well known in the art, again relying on official notice 
without any evidentiary support 

Applicant traverses this rejection on grounds that no sufficient motivation to combine has been 
shown, and furthermore the following are not disclosed by Paltenghe nor the arguments of 
official notice: 

- A plurality of payment verification systems (claim 26). 

- A payment proxy system (claim 27) as argued above. 

- A transaction capture database storing information regarding transactions verified by a payment 
proxy system (claim 28). 

- A payment proxy interface, runtime payment logic (claim 29) as argued above. 

- A plurality of payment connection modules (claim 29). 

- A plurality of back-end processing systems that each include a plurality of payment verification 
systems, an accounting/billing system and one or more order fulfillment systems (claim 30). 

- A customer database storing customer-specific transaction processing rules (claim 31) as argued 



- Runtime scripting information for determining how to process particular transactions (claim 



- A merchant database storing merchant-specific payment verification rules, (claim 33.) 

Again, Applicant does not find any support in the record for the arguments of rejection for claims 
26-33, and challenges the Office under MPEP § 2143.04 "C" to provide documentary support for 
each of the elements of those claims. The arguments refer to paragraph 45 of Paltenghe, but that 
does not disclose any of the elements of claims 26-33 as listed above. 



above. 



32.) 
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1 1 . The Office expresses that applicant's arguments are rendered moot by the new grounds of 



with respect to the pending claims are withdrawn. 

12. The Office gives the contact information of the examiner, his supervisor, and gives mailing 
and other information for addressing a response. . 

Finally, difficulty has been continued in following the arguments of this office action due to a 
lack of accurate references and explanation of why items pointed to are considered to be within 
the meaning of the terms of the claims. Applicant reminds the Office of its duty under 37 CFR 
1.104(c)(2) to provide the pertinence of each reference, if not apparent, clearly explained. 
Applicant therefore requests and requires, for each point of rejection, that the Office supply 
specific locations and interpretations relied upon where it is not readily apparent. 

The applicant's representative would be grateful to be contacted at the below telephone number, 
should there be any remaining questions. 



rejection, which applicant understands to mean that rejections made in all prior office actions 



. Respectfully submitted this day of June, 2005. 





Everett D. Robinson 



Reg. No. 50,911 

PARSONS, BEHLE & LATIMER 

201 South Main Street, Suite 1800 

P.O. Box 45898 

Salt Lake City, UT 84145-0898 



(801)536-6724 
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CERTIFICATE OF MAILING 

□ I hereby certify that this correspondence is being deposited with the United States Postal Service 
"Express Mail Post Office to Addressee" service under 37 CFR 1.10 with sufficient postage and is 
addressed to: 

□ I hereby certify that this correspondence is being deposited with the United States Postal Service with 
sufficient postage as first class mail in an envelope addressed to: 

Commissioner for Patents 
Mail Stop Amendment 
P.O. Box 1450 
Alexandria, VA 22313-1450 



Signature. 



CERTIFICATE OF TRANSMISSION 

I hereby certify that this correspondence is being facsimile transmitted the United States Patent and 
Trademark Office, 



on 



Typed or printed name of person signing this certificate: 



□ Everett D. Robinson 



□ 




□ Fax No. (703) 



on 



Typed or printed name of person signing this certificate: 
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